https://news.hada.io/topic?id=21623
이하 전문성의 최신성이 떨어진 상태에서 씀.
비지 루프를 언급했는데, 매니코어 서버에서는 대부분 문제가 없다. 그러나 우리의 커널은 2코어 수준에서도 잘 동작하도록 만들어진 역사성이 있다. 지금의 서버는 매니코어 시대이므로, 코어 1개가 쌩뺑이를 치고 있어도 다른 코어가 다른 프로세스들을 처리하면 될 일이다. 거짓 공유등 캐시 중첩(?)구간이나 메모리 공유 부분 문제 등은 일단 논외다. 곰곰히 생각해보니 거기까지 안다고 쓸 자신이 없다.
아무튼 그리하여 최신 커널은 더 많은 커널내 비지 루프를 동원해도 된다. 락도 스핀락이다. 단순! 무식! 뺑이! 노답 3형제!
다만 비지 루프라도 1. 루프 점유 시간이 길고, 2. 가용 코어룰 다 쓴다면 문제가 된다. C언어 식으로 사고하는 사람이 멀티쓰레드/멀티프로세스 코딩을 하면서 자원을 다 뽑아 쓰겠다!! 라고 마음 먹고 코딩하면 문제다. 루프 점유 시간이 길다 하더라도 유휴 코어 자원을 마진으로 확보하는 매커니즘만 있다면 문제 없을 것이다.
문득 생각났는데 100년전쯤에 드로잉을 지원하는 터치스크린 디바이스가 속도를 따라 오지 못한 문제가 있었다. 곡선으로 따라와야 하는데 인터럽트를 씹어먹어 폴리곤이 됐다. 디바이스 드라이버를 보니 강제 스케쥴 처리를 하고 있었던 것 같다. 인터럽트 걸리고 -> 터치스크린이 눌린 동안 -> 계속 CPU를 물고 있으면 -> OS의 다른 기능이 멈춘다라고 가정한 것 같다. 제조사에서 디바이스 드라이버를 다른 표준 디바이스 드라이버의 템플릿을 레퍼런싱해서 그랬을 것이다. 그 디바이스는 빌트인 애플리케이션 외에 부하성 애플리케이션이 추가로 설치될 수 없었고, 멀티 코어였으므로 강제 스케쥴만 풀었다. schedule 류 함수나 wait(0) 류 함수였으리라. 여튼 폴리곤은 곡선이 됐고 나는 우리 마을의 .... 이하 생략. 물론 얼마 지나지 않아 터치스크린 전용 칩들이 알아서 처리하는 시대로 바로 넘어갔다.